Skip to content

CLOUDP-322487 - Webhook clusterrole #393

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

CLOUDP-322487 - Webhook clusterrole #393

wants to merge 8 commits into from
+93 −16

Conversation

nammn
Copy link
Collaborator

@nammn nammn commented Sep 1, 2025 •
edited
Loading

Summary

This pull request introduces Helm chart unit tests to the CI pipeline and ensures consistent naming for ClusterRole and ClusterRoleBinding resources in the Helm chart. The most important changes are grouped below:

Helm Chart Testing Integration:

  • Added a helm-tests target to the Makefile to run Helm chart unit tests using the helm-unittest plugin. The target installs the plugin if necessary and runs tests in the helm_chart directory.

  • Created a test_helm_unit function in .evergreen-functions.yml to execute the new Helm unit tests as part of CI.

  • Added a unit_tests_helm task to .evergreen.yml and included it in the unit_tests_task_group to ensure Helm unit tests run with other unit tests in the CI pipeline.
    Helm Chart Improvements and Testing:

  • Updated operator-roles-webhook.yaml to dynamically generate consistent names for ClusterRole and ClusterRoleBinding resources based on the operator name and namespace, preventing naming conflicts across multiple installations.

  • Added a new Helm unit test suite (webhook_clusterrole_test.yaml) to verify that ClusterRole and ClusterRoleBinding names are consistent and unique per installation.

Example

the new names:
binding
<name>-<ns>-webhook-crb
role
<name>-<ns>-webhook-cr

old names:
binding
<name>-<ns>-webhook
role
mongodb-kubernetes-operator-mongodb-webhook

Proof of Work

  • green ci
  • helm chart unit test as part of unit test: Link (IMO that unit test is more for documentation than actually testing, its nice to have a view how those names are generated in the end)

Checklist

  • Have you linked a jira ticket and/or is the ticket in the title?
  • Have you checked whether your jira ticket required DOCSP changes?
  • Have you added changelog file?

@nammn nammn added the skip-changelog Use this label in Pull Request to not require new changelog entry file label Sep 1, 2025
@github-actions GitHub Actions
Copy link

github-actions bot commented Sep 1, 2025 •
edited
Loading

⚠️ (this preview might not be accurate if the PR is not rebased on current master branch)

MCK 1.3.0 Release Notes

New Features

Multi-Architecture Support

We've added comprehensive multi-architecture support for the kubernetes operator. This enhancement enables deployment on IBM Power (ppc64le) and IBM Z (s390x) architectures alongside
existing x86_64 support. Core images (operator, agent, init containers, database, readiness probe) now support multiple architectures. We do not add support IBM and ARM support for Ops-Manager and the init-ops-manager image.

  • MongoDB Agent images have been migrated to new container repository: quay.io/mongodb/mongodb-agent.
    • the agents in the new repository will support the x86-64, ARM64, s390x, and ppc64le architectures. More can be read in the public docs.
    • operator running >=MCK1.3.0 and static cannot use the agent images from the old container repository quay.io/mongodb/mongodb-agent-ubi.
  • quay.io/mongodb/mongodb-agent-ubi should not be used anymore, it's only there for backwards compatibility.

Bug Fixes

  • This change fixes the current complex and difficult-to-maintain architecture for stateful set containers, which relies on an "agent matrix" to map operator and agent versions which led to a sheer amount of images.
  • We solve this by shifting to a 3-container setup. This new design eliminates the need for the operator-version/agent-version matrix by adding one additional container containing all required binaries. This architecture maps to what we already do with the mongodb-database container.
  • Fixed an issue where the readiness probe reported the node as ready even when its authentication mechanism was not in sync with the other nodes, potentially causing premature restarts.
  • Fixed an issue where the MongoDB Agents did not adhere to the NO_PROXY environment variable configured on the operator.

Other Changes

  • Optional permissions for PersistentVolumeClaim moved to a separate role. When managing the operator with Helm it is possible to disable permissions for PersistentVolumeClaim resources by setting operator.enablePVCResize value to false (true by default). When enabled, previously these permissions were part of the primary operator role. With this change, permissions have a separate role.
  • subresourceEnabled Helm value was removed. This setting used to be true by default and made it possible to exclude subresource permissions from the operator role by specifying false as the value. We are removing this configuration option, making the operator roles always have subresource permissions. This setting was introduced as a temporary solution for this OpenShift issue. The issue has since been resolved and the setting is no longer needed.
  • We have deliberately not published the container images for OpsManager versions 7.0.16, 8.0.8, 8.0.9 and 8.0.10 due to a bug in the OpsManager which prevents MCK customers to upgrade their OpsManager deployments to those versions.

@nammn nammn marked this pull request as ready for review September 2, 2025 09:49
@nammn nammn requested a review from a team as a code owner September 2, 2025 09:49
nammn
nammn commented Sep 2, 2025
View reviewed changes
helm_chart/templates/operator-roles-webhook.yaml
@@ -1,12 +1,13 @@

{{/* This cluster role and binding is necessary to allow the operator to automatically register ValidatingWebhookConfiguration. */}}
{{- if and .Values.operator.webhook.registerConfiguration .Values.operator.webhook.installClusterRole }}
{{- if not (lookup "rbac.authorization.k8s.io/v1" "ClusterRole" "" "mongodb-kubernetes-operator-mongodb-webhook") }}
{{- $webhookClusterRoleName := printf "%s-%s-webhook-cr" .Values.operator.name (include "mongodb-kubernetes-operator.namespace" .) }}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i've changed both names, because one was dynamic and one not - causing upgrade problems. Now both are just a new set of names.

viveksinghggits
viveksinghggits approved these changes Sep 2, 2025
View reviewed changes
@nammn nammn removed the skip-changelog Use this label in Pull Request to not require new changelog entry file label Sep 2, 2025
lucian-tosa
lucian-tosa reviewed Sep 2, 2025
View reviewed changes
helm_chart/tests/webhook_clusterrole_test.yaml Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this test verify that subsequent upgrades of the chart does not break the rbac?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no - we only have e2e tests that verify latest (1.2.0) -> current (code build) and those are passing.

We don't have current -> current, but I don't see how this could be failing, do you think we should test this in particular?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally we should have a test in our CI that upgrades the released helm chart version to the current local version to test things.

Copy link
Collaborator Author

@nammn nammn Sep 2, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we only have e2e tests that verify latest (1.2.0) -> current (code build) and those are passing.

isn't that exactly that - or are we talking about different things?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its operator_upgrade_ops_manager we have suite of those

mongodb-kubernetes/docker/mongodb-kubernetes-tests/tests/upgrades/operator_upgrade_ops_manager.py

Line 148 in f29ac63

operator = get_default_operator(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@viveksinghggits viveksinghggits viveksinghggits approved these changes

@lucian-tosa lucian-tosa lucian-tosa left review comments

@anandsyncs anandsyncs anandsyncs approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@nammn @anandsyncs @viveksinghggits @lucian-tosa